J-kanban 玄人志向 » {|ihower.idv.tw| blog }

Feeds

6429 items (6429 unread) in 32 feeds

(20 unread)

• 名师博客-华夏智慧 (20 unread)

Chinese (5180 unread)

• robbin的口水 (18 unread)
• 东京流行通讯 (77 unread)
• 思维的乐趣 (777 unread)
• InfoQ (1371 unread)
• 花钱的年华 (28 unread)
• lighty ror backup (10 unread)
• 心灵的自由 (15 unread)
• {|ihower.idv.tw| blog } (43 unread)
• 天涯海阁 (363 unread)
• 51CTO技术博客 (64 unread)
• Midnight Blog - Home (30 unread)
• David H. Hansson博客中文版 (15 unread)
• 汉语编程的BLOG (158 unread)
• Ruby新闻聚合 - Ruby中文社区 (904 unread)
• JavaEye论坛精彩帖子 (444 unread)
• 美景旅游博客 - Meijing Travel Blog (67 unread)
• 微趣 - minifun.cn (547 unread)
• 阮一峰的网络日志 (124 unread)
• Lighty RoR (30 unread)
• IceskYsl@1sters! (95 unread)

Japanese (1137 unread)

• TECHSCORE (53 unread)
• 最速インターフェース研究会 (44 unread)
• たたみラボ (24 unread)
• モバイル魂 － 携帯業界研究 (20 unread)
• 結城浩の日記 (330 unread)
• 東京流行通訊 (373 unread)
• 速聴 (13 unread)
• Kawa.net（川崎有亮） (218 unread)
• 2061:Maxオデッセイ (62 unread)

English (92 unread)

• Midnight Oil (41 unread)
• RailsOnWave (51 unread)

{|ihower.idv.tw| blog } (43 unread)

• August 13, 2008
• 5:11

  誰說人是理性的

   » ‎ {|ihower.idv.tw| blog }

  
  好久沒看經濟類的書，這本書從人的非理性層面切入，並用有趣的實驗導出令人驚奇的結果，還蠻有趣的。

  1. 比較才能做決定。提供 A,-A, B 三種選項，其中 A,B 無法比較，A 比 -A 好。實驗出人們會 75% 去選A，即使 A,B 無法比較。這個 -A 的效果稱作誘餌效應。
  2. 定錨點的影響，隨機的定錨點先入為主影響你的決策。
  3. 只要有”免費”這個字眼，就難以抗拒。2塊降價變1塊跟1塊變免費的效果是天差地遠。
  4. 社會規範與市場規範，只要一提到錢，就變成市場規範。(錢不是萬能)
  5. 不同的情緒狀態所做的決定會不同，高張的情緒容易失去理智。
  6. 預先承諾機制可以幫助解決拖延問題
  7. 如果擁有某樣東西，就會對這樣東西估價較高。所有權會讓你的損失趨避心理變得強烈，只想到失去時的損失而忘記會獲得的利益。(由簡入奢易，由奢入簡難)
  8. 人會盡量保留多一點選擇，即使這樣得付出極高的代價。就像父母匆忙帶著小孩到處學才藝，四處奔走不僅讓人緊張，也不符合經濟效益。很多時候在兩個相似的選項中做選擇，猶豫的時間代價比兩者細微的差異損失更多。
  9. 預期心理影響感官認知。但若事後知道內情也不會影響一開始的經驗。
  10. 安慰劑的暗示效果，因為人們相信它有效，所以也出現治療效果。價格因素也會影響效用，貴的比較有效。關於醫療與安慰劑的道德問題是個很大的議題。
  11. 一旦有機會，許多誠實的人都會欺騙，一旦決定作弊，卻不會受被逮到的風險高低所影響，對小的欺騙來說不會思考成本效益分析。有趣的是如果有任何誠實概念進到腦子(例如回憶十戒或簽署榮譽制度)，就會容易保持誠實。
  12. 當人們騙的不是現金的時候，欺騙行為較容易發生。甚至即使改成用代幣(多一層轉換手續而已，還是可以換現金)，欺騙的比例也會大增。當交易媒介與貨幣無關時，我們就更容易合理化自己的行為。
  13. 行為經濟學了解人容易受到情境、不相關的情緒等不理性因素影響，所以希望利用工具、方法與制度來幫助我們提高決策品質。

  我想這本書真正精采的地方在作者設計的這些有趣實驗，作為一本通俗讀物還蠻值得推薦的。不過我在想如果是科普觀點：認知心理學家、生物學家等科學家應該會有更好的解釋為什麼人類會這麼做吧，我自己是認為”人” 的這些非理性決策不是為了找到最佳解，而只是極小化選到最差解的可能 (也許就代表死亡)罷了。

• August 02, 2008
• 1:10

  Rails plugins@COSCUP 2008

   » ‎ {|ihower.idv.tw| blog }

  

  一年一度的 COSCUP 聚會又來了，這次我也投了一場 Rails plugins used/created in Registrano 約二十分鐘的演講。題目顧名思義就是介紹 Registrano 所用到的 Rails open source plugins，就是因為有這麼多好用的開放原始碼插件，才得已讓 Registrano 這個網路服務能夠敏捷地構建出來。

  敝社和多這次同時也贊助了活動網站設計，當然還有報名網頁(Registrano)。除了我的 talk，還有 xdite 也會分享 Rails 2.1 的新功能介紹。希望大家多多捧場。

  如果您對 Registrano 這項服務有任何想法，屆時也歡迎給予指教，並致贈您 Registrano 折價卷。

• July 07, 2008
• 2:47

  實戰敏捷開發 Practices of an Agile Developer (2)

   » ‎ {|ihower.idv.tw| blog }

  這一章是 Delivering What Users Want。我們總是幻想客戶一開始就確切告訴我們需要什麼，然後做完收工拿錢即可。不過事實總是中途加入一開始沒有提到的功能跟規格變更。敏捷開發不去試圖”擊敗”這些變更，而是把重點放在如何快速辨認及適應這些改變，並在時程及預算內做出真正符合用戶需求的軟體。
  

  Let Customers make decisions (讓金主做決策)

  當碰到設計上的決策時，尤其是 business-critical 決策，例如有兩個解決方案，一個複雜耗時長，另一個較簡單花較少時間。這時不要自己先決定，而是準備好資料(優缺點跟耗時估算)向金主(客戶)並用他們聽的懂的語言，讓他們決定。我自己的經驗是常常你打算做的沒有客戶想要的這麼複雜唷，這時候就可以省下這些時間去做真正客戶要的。

  記得紀錄下來每個決定跟理由，當然你的問題也不能太技術細節，而是要有關係到 business。當然客戶也有可能說不知道，那麼你只好說出你覺得最好的建議。

  Let Design Guide. Not Dictate (讓設計引導，而非鉅細靡遺)

  設計文件不要細節到告訴你怎麼實做，而是一張地圖告訴你方向。
  傳統作法特別強調設計階段，希望設計文件盡可能詳盡，但是 agile 則建議你盡早進入開發(development)階段，這不代表忽略 design 的意思，基本的 key diagrams 仍是一開始就必須先思考。

  agile 建議盡早開始的理由是，再多的設計也只是基於你對當前的需求了解，一旦開始 coding，一切都會變化，不需要把時間浪費在詳盡的設計。

  “There’s no sense being exact about something if you don’t even know what you’re talking about.” -John von Neumann” 馮曼紐大師如是說

  當 designer 要求 coder 必須按照設計實做，但是系統現實和已經存在的程式告訴 coder 這並不會是最好的設計，真是糟糕，設計的時間已經花了，沒有時間重來。於是 coder 在有壓力的情況下只好實做出他明知不對的程式。這種嚴格要求 requirements-design-code-test 流程的瀑布式開發已經落伍了。

  而 Agile 要說得是，只有在要被實做的時候才有需要詳細的設計。我們可以將設計分成兩個層次，策略性的(strategic)和戰術性的(tactical)，前者不需要詳細到 mehods 參數，物件之間的互動次序，這些都是戰術層次。前者可以討論到可能的 class design 以及他們的責任，及 CRC card design 也很適合，一個 Class 被描述成 Class name, Responsibilities, Collaborators 等，一個適合的設計即使需求稍有變化也可以輕易實做出來。

  一個好個策略性設定應該扮演地圖角色，告訴你目標方向和限制，任何設計都只是一個起點，一旦開始開發你就必須一直演進下去。

  agile 的精神不是告訴你設計、計畫不重要，缺少任何設計就進入 coding 是非常危險的，就像美國總統艾森豪所說得 ” The plan is worthless. The planning is essential.”，設計的過程才是收穫最多的地方。(XP流程有本書叫 Planning Extreme Programming, by Kent Beck&Martin Fowler 也是這個原因，書名叫 Planning 而不是 Plan)

  Justify Technology Use (評估使用的技術)

  根據需求來選擇使用什麼技術、語言或 framework，每項技術都有優點缺點跟 trade-offs。
  “The less code you write, the less you have to maintain”。可以下載到的東西，不需要自己寫。

  Keep It Releasable (保持可以 Release 的狀態)

  每次 checked-in 的 code，都要是可以讓系統可以執行的 code，避免 unreleasable 的狀態。
  當你跟一個團隊一起工作，你必須了解到你的 changes 是會影響整個 team 的生產力，一個 unreleasable 的狀態讓整個 team 卡在那裡。你不能忍受別人 check-in 的 code 把程式搞爛到不能動，別人也不喜歡。在 check-in 之前，請確認以下兩個步驟：

  1.在 check-in 前跑一遍所有的 unit tests
  2.check out 最新的程式碼，時常發生別人剛 check-in 一段與你不相容的程式碼。

  當然，最好的辦法就是建置一個 continuous integration system (CI)，當有一個 check-in 時會自動 check-out 出來執行測試並產生通知。

  說比做容易，將 database scheme 跟 external files 也送進版本控制系統，讓相關更動都可以被測試。大的更動可以透過 version control branch 分支來處理這個問題。

  如此一來，一個隨時可以動的軟體，金主、客戶、QA都隨時可以看到最新會動的版本。

  Integrate Early, Integrate Often (盡早整合、時常整合)

  許多人會會延後整合，畢竟系統最後再整合就好，只要現在自己的 sub-system 可以動就好。但如果你一直只開發自己的東西，而越慢跟別人的東西整合在一起，越是辛苦。建議整合的次數從一天好幾次，到至多兩三天也至少有一次。

  我自己的經驗是，你在分支(branch)開發一個功能，而主幹(trunk)同時也有別人在繼續進行，這時候建議時常要從 trunk merge 進你的 branch，可以的話每天進行，而不是等到最後才進行合併，最後才合併可能就merge不起來了，差異太大。

  隔離開發(isolate)可以讓你開發更快避免干擾，但 isolate 與 integrate 不是不能同時進行，我們可以透過 mock object 技術在 isolate 的環境中測試你的 sub-system。透過盡早整合，你會發現你的 sub-system 與其他 sub-system 如何互動，越早了解問題所在，修好它的工作困難度就越低。

  Automate Deployment Early (及早自動化佈署)

  自動化安裝步驟(Install or deploying your product should be easy, reliable and repeatable)。為什麼需要呢? 反正又不常裝，手動就好啦?
  安裝步驟不只有你而已，還有 production 跟所有 programmers 跟 tester。如果最後 deploy 才做，常會發生東少西少裝東西的情況，常常機器環境改了程式就壞了。趁早做好安裝程式也可以讓 QA team 及早測試不同機器環境跟設定的 deployment。安裝步驟中也可以 check 必要的 dependency，趁早排除環境因素。
  有了自動化佈署，在 web 專案中，可以快速上線的能力將會非常方便，特別是有bug馬上修好的時候。
  另外一提的是記得提供 user 完全移除的辦法。而 Day One 就有安裝程式的另一個好處是，馬上就可以給客戶可以安裝的 demo 版。

  Get Frequent Feedback Using Demos (透過經常的Demo得到回應)

  我們總是時常聽到”凍結需求”的要求，但現實是需求如流水。如果真定住，往往也是錯的。沒有人的心思是固定的，特別是你的客戶，這是人性啊。當提出需求後，總是還會繼續想怎樣實做會更好。如果你只是依照一開始的需求去做，那最終是不會讓客戶滿意的，因為你只是生產出他們開口要的，而不是他們想要的。

  解決之道是降低 iteration interval 開發週期時間，我們在一個 iteration 做好分析/設計/實做/測試，然後得到 feedback。過長的週期容易走偏，持續性的短週期與客戶溝通，對每個人都是有利：客戶可以知道進度，而且可以儘快把想要的修改跟 feedback 表達出來，而程式設計師也可以因此讓程式更接近客戶想要的，客戶也可以依據開發的情況和還有多少時間預算，來表達開發的優先順序，

  儘快得到 feedback 吧，如果你的週期是一季以上，請改用一週到四周 (單雙週較理想) 向客戶 demo 並得到 feedback。這些 feedback 包括錯誤修正、建議、需求更改，功能加強等等都需要利用 ticket tracking system 加以管理。

  在表達需求的時候，建立一份 Project Glossary 術語列表是很重要的，讓程式設計師跟客戶對名詞詞彙取得定義，可以大大避免誤解。

  Use Short Iterations, Release in Increments (短開發週期，釋出新版本)

  有了一到四周的開發週期，接下來我們還希望上線的 release 是以 1~6個月為週期，釋出即使功能少，但是穩定可以運作，可以提供客戶操作價值的版本。一個計畫超過數年的軟體還無法 release 出一個版本讓客戶使用，註定失敗。

  找到產品最重要的核心功能，儘快上線讓真正的使用者去使用。沒有人願意去等超過一年的軟體。即使是 NASA 複雜太空梭計畫也可以使用這種 incremental 式的開發，再大的產品也可以拆出有用的一整塊實做出來。

  快點上線的好處是可以儘快獲得收益，讓專案更有力量繼續進行，得到 user feedback 什麼是用戶真正最想要的功能，什麼是你本來想要但是其實客戶不需要的功能。開發人員也希望快點得到成果，一個計畫一年後才釋出的軟體讓人提不起勁，能得到真正用戶的正向鼓勵絕對有助於生產力。

  而 iteration 開發週期不是一定要緊接著的，我們也可以在以四周為單位的 iteration 中安排一週的 maintenance week 然後再進到下一個 iteration。

  Fixed Prices Are Broken Promises (小心定死的價格)

  每個客戶來總是期望問多久完成? 多少錢? 但是一個大的固定預算，固定時程的軟體專案卻是非常危險的，尤其是差異性高的軟體產品，我們較難根據上次的開發經驗判斷這次的需求會花多少功夫。傳統上為了能夠做較大的案子，就會去做很多的 COCOMO 或 Function Point 分析，但是這些都不是 agile 所希望的方式。

  Agile 會建議你盡量將第一次的約簽小，在6~8周內完成一個可以上線的產品。有了第一次的經驗，我們就有更好的實戰估計能力。對客戶來說也是保障他可以在短時間內看到成果，也讓客戶可以根據預算控制他們要的功能。當然，如果一點空間也沒有，那麼只好加強估計的能力了。

• July 05, 2008
• 16:53

  使用 Passenger (a.k.a mod_rails) 開發 SSL 網頁

   » ‎ {|ihower.idv.tw| blog }

  承上一篇使用 mod_rails 當做開發環境，要在 local 開發測試 SSL 網頁，使用 mod_rails 是最方便的選擇，以下是我在自己 Mac Leopard 上的安裝步驟：

  1. 首先是產生 SSL Keys
  
# Generate certificate
openssl req -new > server.csr
openssl rsa -in privkey.pem -out server.key
openssl x509 -in server.csr -out server.cert
-req -signkey server.key -days 365


  然後把產生出來的 server.key 跟 server.cert 放到 /etc/apache2/ 下，server.cert 改名成 server.crt，然後都 chmod 成 400 唯讀。

  2. 編輯 /etc/apache2/httpd.conf，打開 Include /private/etc/apache2/extra/httpd-ssl.conf

  3. 編輯 /etc/apache2/extra/httpd-ssl.conf，確認 SSLCertificateFile 跟 SSLCertificateKeyFile 指向步驟一中的兩個檔案。

  4. 編輯你的 vhost 設定，加入以下：
  
NameVirtualHost *:443


  5. 之前設定好的 <VirtualHost *:80> 區段整個複製一份，並改成 443。然後在其中加入以下：
  
RequestHeader set X_FORWARDED_PROTO 'https'


  至此就裝好了，重開 apache 即可，還蠻簡單的。

• June 16, 2008
• 23:01

  實戰敏捷開發 Practices of an Agile Developer (1)

   » ‎ {|ihower.idv.tw| blog }

  

  敏捷軟體開發一直是和多內部開發的核心概念，強調個人、合作、回應和使用工作軟體(wiki, version control, unit testing, build automaion)，2001年由一群軟體開發者發表宣言如下：

  1. 個人及互動勝於流程與工具
  2. 可用的軟體勝於詳盡的文件
  3. 與客戶合作勝於合約談判
  4. 回應變化勝於墨守計畫

  軟體開發是連續(continuous)的，不是最後才測試，也不是最後才佈署，更不會停止收集需求跟feedback。正是因為開發軟體是如此複雜的活動，任何種類的錯誤如果不儘快修正，往往最後就會無法控制的失敗，因此唯有每天不斷的一點一滴的去修正，每天解決一些比較小的問題而不是最後脫韁野馬的大問題，這才是解決的辦法。

  何謂 Agility 的定義，作者給了：
  “Agile development uses feedback to make constant adjustments in a highly collaborative environment.” (敏捷開發是一個在高度合作的環境中不斷根據回應來做修正的開發方式)

  透過經常性地建構出可以實際使用的軟體，我們持續得到 feedback。程式碼會因為需求擴充而不斷地被修改重構演進。工作的流程被拆成一至四周的短 iterations，每次透過 demo 得到 feedback，確保方向正確。

  敏捷開發最大的不同到底是什麼呢? 這本書不談方法論流程(XP、Scurm等)，而是談人本身，談團隊本身，談如何成為一個敏捷的開發人員。書的每一章由數個 Tips 組成，整本書共45個 Tips 來敘述什麼是敏捷的做法。這本書也得到2007年的 Jolts Productivity Award。

  前兩章 Beginning Agility 跟 Feeding Agility 講的是基本的專業態度：

  Work for Outcome (產出至上)

  責怪不能解決問題。當出問題的時候，實際解決問題才是產出，而不是找兇手。

  Quick Fixes Become Quicksand

  為了很快地修好bug，即使不是很了解 code 怎麼運作，還是不明究理地加了奇怪的code修好了 (word-around)，因為寫這樣會炸，所以加了一行例外條件，blahblah… 然後沒人知道加那個條件是為什麼。anyway… 下一個 programmer 看到這行怎麼辦？ 有些 programmer 也許就跳過看不懂的這行，反正可以 work 就好。好的programmer 會搞清楚”為什麼”需要這行，更重要的是更會思考會有什麼副作用。

  當一年一年過去，如果都沒有好的 programmer 在 refactor，可想得知這些 code 會恐怖到什麼程度，新增功能或fixed bug 將越來越困難。

  粗淺的修正而沒有深度了解問題及可能的後果，也許當下 it look like it works，但是他傷害的程式可讀性，你可能會碰到有人說”不要改那裡，因為blah blah”，但當他離職了，就沒有知道那裡是幹麼的。

  有幾種方式可以改善：

  1.不要讓 developer 完全獨立寫 code，developer 要花時間去看別人的 code，確保程式的可讀性及可以理解。程式是寫給人看的，不是給機器看的。

  2.寫 unit testing，在寫 testing 的過程中，你會轉換思維成如何設計 API，這將幫助你設計出更好呼叫及更清楚的程式。好的 unit testing 甚至可以當做一種可執行的文件，這也是 BDD 所強調的思維。

  Criticize Ideas, Not People (對事不對人)

  當有人提出一個點子的時候，不要指責，不要批判，只要說明你關心的問題點即可，討論這個問題而不是爭吵。保持專業，盡量問建設性的關鍵問題，而不是針對個人的情緒性發言。

  每個人都有好想法跟不好的想法，別害怕都提出。試著針對優缺點討論，大部分的選項都是有 trade-offs 的。與其說決定最好的解法，不如說要大家同意在這個情境下什麼解決較好。

  Damn the Torpedoes, Go Ahead

  做正確的事，敢於溝通實話。例如接到一個爛程式要新增功能，你是要讓他爛到最後，還是提出優缺反應說這個很爛要好好改寫。

  當你開發到一半，發現自己的方向不對了，勇於說出自己的新解法，即使需要更多時間，詢問看看其他人的想法。而不是默默的交差了事。誠實與勇氣贏得信任。

  像布丁大人就常嚴厲地說：”這樣對嗎？”…. 當你知道什麼是對的，就應該去做，而不是含混了事。當你了解現在的錯誤，要有勇氣跟你的團隊/老闆甚至是客戶說明，即使這樣可能會影響時程。

  實做一個新功能時，也許你發現前人用的是 copy-paste 大法，你也可以這樣做，而且也許一下就做好了。請鼓起勇氣跟大家說你要重構他。

  當團隊不同意你的作法的時候，也許是你的理由解釋的不夠，為什麼這是對的。當團隊依然不同意你的作法的時候，也許他們才是對的。

  當然，看到奇怪的code，不要第一時間把他丟掉改寫，沒有足夠的了解不是勇氣而是莽撞。

  Keep up with change (跟上科技變化)

  有人說科技進步很快，永遠跟不上乾脆就不學了。但東西多半是漸進步的，常常跟上才不會跟不上。
  不用精專每項新技術，但保持警覺不要忽略，持續規律地學習跟上腳步。這一行不是學校畢業就可以停止學習。
  了解為何新技術這麼重要? 是要解決什麼問題? 他要用在哪裡?

  Invest in Your Team (投資你的團隊)

  不要藏私，分享能讓團隊興奮的技術或技巧，提昇團隊背景知識絕對有助於溝通與開發效率。建議可以一天一週安排一場簡短的技術 presentation。

  Know when to unlearn (知道什麼是過時的技術)

  技術在進步，有時候必須把舊東西給丟掉學新的，例如CPU變快了，Developer time 變重要了，很多以往的舊寫法不再適用必須丟掉。不過最困難的第一步就是了解到是否用了過期的解法。

  Question until you understand (問為什麼直到了解)

  不要人家告訴你什麼通盤接受，在 debugging、了解 requirement 跟 design 時，要好好了解並提問。系統很複雜， debug 不能只看表面徵兆而已，而是要了解什麼是真正的問題所在。多問 why 想想到底是什麼原因。例如人家跟你說系統每週 reboot 就好啦，但是 why?

  Feel the Rhythm (節奏)

  持續有節奏地規律處理小任務總是比較簡單，不要讓問題累積到某一天突然炸出來而無法處理。團隊使用 interation 的方法，將專案的工作任務以一到四週為單位。

  而對個人來說，以天為單位，今天結束前就應該把東西測試過然後 check in，如果今天沒辦法告一段落，很可能最好明天得重來。而 stand-up meeting 也會是每天規律的工作項目。

  —-
  念到這裡，雖然都是看似一些很基本的 coding 專業態度，但這些價值觀卻往往比所謂的開發流程還重要不是嗎？

• June 04, 2008
• 4:35

  RailsConf 2008 投影片選

   » ‎ {|ihower.idv.tw| blog }

  一年一度的盛事結束了，大概翻了一遍目前可供下載的 RailsConf 2008 Presentation Files，我自己最喜愛以下四份投影片，談如何寫出更好的 Rails/Ruby 程式碼：

  1. Advanced Active Record Techniques Best Practice Refactoring
     用一個實際的例子，告訴你如何正確運用 Active Record 機制，將大部分的 Controller 移至 Model。
  2. The Worst Rails Code You’ve Ever Seen (and how not to write it yourself)
     挺有趣的投影片，舉例一些有點誇張的爛code。結論是請把 Ruby 基礎學好啊，跟厲害的人一起 co-work，多唸點書 (啊啊~可是講者的 Rails Way 一書好厚啊~)。
  3. Refactoring Your Rails Application
     Rails 重構型錄 Paper 真是不錯，如果再搭配 Martin Fowler 重構一書服用，保證你對如何寫出漂亮的code超有想法。
  4. “Design Patterns” in Ruby
     引述結論： “traditional” design patterns rely heavily on structure to solve problems, dynamic languages use language facilities to create simpler solutions.
• June 02, 2008
• 6:03

  使用 httperf 做網站效能分析

   » ‎ {|ihower.idv.tw| blog }

  Update(2008/7/8): 推薦Topfunky’s bong搭配使用，非常簡單。

  做網站效能調校，一件重要的事情就是量測(measure)。調之前測一次，調之後再測一次才知有沒有藥效。

  “Server 回應 requests 的速度有多快？” 就是一個最基本的問題。這技巧也叫做黑箱分析(Block-box analytic)。Advanced Rails 一書中給了幾點特別要注意的事項：

  1. 有台 front end server (Apache,Nginx等)先測試 static files，這個數據是一個上限。Rails 不會比這更快了。
  2. 找近一點的地方測，減少網路 latency 的變異性
  3. 不要用 server 同一台測試，雖然 CPU 不太會是問題，但是 I/O 可能會有影響。

  觀測的數據除了平均，更要看標準差跟計算信賴區間，因為除了平均之外，低變異也很重要。基本的統計學告訴我們，相差平均一個標準差可以涵蓋 68% 的資料，相差兩個標準差就可以涵蓋 95% 的資料。因此我們可以算出 95% 的信賴區間，也就是 95% 發出的 requests 中，可以在幾秒到幾秒內回應。基本的統計知識是做 analytic 必備，Zed Shaw 為此還寫了篇Programmers Need To Learn Statistics Or I Will Kill Them All。

  在 Mac 上透過 MacPorts 安裝 httperf 很簡單，輸入 `sudo port install [httperf`] 即可。

  [httperf] 的用法

  基本用法是指定 Server、Port、URL和總共要發出多少個 requests：
  
[httperf] --server project1.local --port 3000 --uri /events --num-conns 1000


  其中最重要的 output 資訊就是 Reply rate 有平均和標準差的那一行。要注意的是 [httperf] 是每五秒抓一次樣本(sample)，根據 [httperf] 的建議是希望至少有 30 個樣本數才能得到準確的標準差，因此當 sample 數太少的時候，要記得把 –num-conns 往上加。

  另一種算壓力測試，也就是去測試“Server 每秒可以承受多少 requests？”。請再加上 –rate 跟 –hog 參數：

  
[httperf] --server project1.local --port 3000 --uri /events --num-conns 5000 --rate 500 --hog


  逐步把 rate 往上調，直到 server 超過極限時，就會開始少 replies (有 requests 被 drop off 了) 並出現 Errors。

  Rails 的相關設定

  有幾項設定可以增加更多相對比較數據：

  1. 透過 config.action_controller.perform_caching = false 的設定可以在 production mode 也把所有 caching Page, Action, Fragment 暫時關掉
  2. 暫時註解掉 before_filter 中的權限檢查
  3. 透過 session :off 關掉 session

  本文參考資料

  1. Advanced Rails Chap.6 Performance
  2. Peepcode">[httperf">Peepcode] httperf screencast
• May 30, 2008
• 9:26

  % sudo make 上線

   » ‎ {|ihower.idv.tw| blog }

  你的腦海裡是否曾經出現這樣的聲音：

  「這東西太酷了，誰趕快來做一下。」

  你是否有很多點子，卻又沒有做事的動力？

  在 sudomake.com 這個地方，每個人都可以成為英雄。無論是需要超人來幫你，亦或你行有餘力能夠助人，都可以來此。

  不如就用這則漫畫來解釋它的功能吧：

  （出處）

  還是不懂嗎？沒關係，立刻登入開始玩玩看，一切都很簡單明瞭。

  前往 http://sudomake.com

  本篇文章共同發佈於Handlino網站。

• May 23, 2008
• 21:45

  少就是多) Ruby on Rails

   » ‎ {|ihower.idv.tw| blog }

  知名的 Web design 線上雜誌 A List apart No.257期少見地刊出 Rails 入門介紹，心血來潮來做翻譯，斷斷續續翻潤了好幾次，覺得文章看起來沒什麼，翻起來好長啊。
  終於再度體會 text.plain 果然是最難寫的格式。寫投影片，做翻譯比寫程式還辛苦…orz

  以下翻譯自 Creating More Using Less Effort with Ruby on Rails by MICHAEL SLATER

  如果你開發網站，想必應該聽過 Ruby on Rails (RoR) 的大名。但是如果是網頁設計師或前端工程師，或除了PHP沒有用過其他框架，那麼採用 Ruby on Rails 方案似乎會是一個很大的改變。在這篇文章中，我希望能夠除去 Ruby on Rails 神秘的面紗，並說服你採取行動，這將會非常值得如果你的需求符合下述的 Ruby on Rails 甜蜜點。

  學新方法去做本來就會做的事情，還要同時學新觀念和新技巧,確實會花你一點時間。直接了當地說，即使是 Ruby on Rails，轉換技術都將會摧毀你的生產力。然而，我相信網站開發者如果開始採用 Ruby on Rails，將變得更有生產力做出更好的網站，以及從中獲得更多的樂趣。

  Rails樂趣

  Ruby on Rails(簡稱Rails)是一個完整的框架，意思是說他包含了前端跟後端。它讓 “要做多種不同工作的人” 開發者能擁有極強有力的工具。即使基本上你只是前端或後端工程師，你仍可以有效率的使用 Ruby on Rails。我們可以清楚定義前端(瀏覽器HTML、CSS和JavaScript)和後端(Ruby和Rails框架)的介面，所以如果你只想要專注在其中一端的話，不需要全盤了解。

  如果你是網頁設計師或前端工程師，你會學到如何使用 Ruby on Rails 樣板系統，而且學一點內嵌Ruby程式碼在 View 檔案。這將讓你成為後端開發者更好的夥伴，因為你可以直接操作 Rails 應用程式，而不是讓某人去整合HTML和CSS。

  因此無論你用前端或後端工程師的角度採用 Ruby on Rails，可以想想看有哪些專案可以考慮採用？

  甜蜜點

  Ruby on Rails 是 Basecamp、Blinksale、43Things、Odeo、Revolution Health、Twitter、YellowPages.com和 A List Apart 這些網頁應用程式和網站的核心。這股Rails熱情也擴展到許多大網路公司。Yahoo、eBay、Amazon和 AOL 都有 Ruby on Rails 專案，而 ThoughtWorks 也正在建立Rails企業級應用程式。但是這麼多不同的 Ruby on Rails 應用程式，有幾個重要的共通最適關鍵。

  當一個網站或網路服務有以下三個特點的時候，最適合採用 Ruby on Rails 方案：

  1. 一個資料庫形式的網站（譯註：一個透過存取資料庫，動態產生內容的網站) 或有足夠規模到適合使用一個強大功能的框架。
  2. 一個特別而不適用於傳統的 CMS 系統 (如果 Joomla 或 Durpal 完全符合你所需，這些系統會是更好的選擇）。
  3. 一個全新的應用，允許開發人員開始全新的資料庫跟軟體架構。

  這些是 Ruby on Rails 應用程式的甜蜜點。應用程式如有這些特性，一旦決定投入學習Rails，採用 RoR 將很可能會比 PHP、.NET或Java 開發的更快速。

  生產力爆增

  一個最主要的理由就是 Ruby on Rails 增加生產力：建立新的應用程式、增加新功能變成容易地多。結合程式語言(Ruby)和框架(Rails)意指你將可以用更少程式碼。更少的程式和更好的架構表示當要改變時相對無痛，所以你可以迭代和實驗更樂意。這將帶我們有更好的網站，而且懷希望地更有樂趣去建構網站。

  當然，採用主要的新工具需要時間的投資，一時沒辦法輕鬆。如果你正專注在一專案，可能不是很適合。但是如果你需要持續建構網站，而且是有一定程度的複雜，一個短期學習 Ruby on Rails 的投資，長期來說將會是值得的。

  要了解我會為什麼相信你可以用 Ruby on Rails 做更多事且寫更少程式，讓我們快速看一下 Ruby。

  遇見 Ruby

  Ruby 是個現代的物件導向語言。在任何 Ruby 程式裡，所有東西都是物件。Ruby也是一個動態語言，這表示：

  Ruby 被動態直譯(就像PHP)，所以沒有編譯(像C或Java)。這加速了迭代式開發。在Ruby裡，變數被使用的時候才被動態指定一個型別，降低了在其他程式語言必須定義跟設定變數。一個Ruby程式可以動態產生程式，修改即使正在執行的自己。Rails內部就使用這個能力，來讓你可以簡單享受所謂的 “Magic”。(你不需要了解到底這個技巧如何運作)
  Ruby 是一個讀寫非常美妙簡潔的語言，但是他的優點不只如此。正因為Ruby可以被強力擴展，Rails框架才可以將他轉換成像是建造網站應用程式的專用語言。

  Ruby(語言)和Rails(框架)是兩回事，他們彼此在很多地方相輔相成。所有 Ruby on Rails 應用程式由Ruby寫成，而Ruby的特性帶給Ruby on Rails很大的影響。有些框架，像是 CakePHP，帶了很多 Rails 點子過去。但是Ruby的能力和彈性給了Rails比許多別的框架更多清楚和彈性。如果你正打算投資學習一個框架，學習Ruby並不會是很大的障礙，而且回報相當可觀。

  Rails 方案

  許多網站並沒有使用任何應用框架：你就寫你要的程式和盡可能到處複製貼上你所需的程式。對小網站來說這ok，但是很快你就會失去控制，亂七八糟的程式碼將很難理解與維護。

  使用像 Ruby on Rails 這樣的框架，很多關於如何組織你的程式碼的決定早就已經為你想好了，而且還有一堆可供挑選使用的函式庫。

  另一個重要的Rails特性是使用 model-view-controller (MVC) 結構來組織每一個應用。 MVC 是一個組織軟體專案的良好設計模式，當你有很多網站或有新人加入工作時，它將帶給你程式碼一致性的結構。它提供個別獨立的檔案，有著乾淨的介面可以分開前端與後端的開發者。

  資料庫與物件

  Ruby on Rails 被設計成用來建構資料庫應用程式，其中許多核心元件專注在與資料庫的互動。Rails的核心函式庫稱作 Active Record，它實做了被稱作物件-關聯對應(ORM)。有了ORM，你可以操作代表資料的軟體物件，然後 Active Record 函式庫將會處理與資料庫的操作。

  這聽起來可能有點抽象神秘，讓我們更具體些。即使不知道任何 Ruby 或任何物件導向語言，我打賭你也可以對下列的程式碼範例有感覺，以下是實際的 Ruby on Rails 程式碼。

  假設你有一個書店網站，你想要加入一本新書。你可以這樣寫：

  
newbook = Book.new


  你正告訴這個 “Book” 類別你要一個空的 book 物件，稱作 “newbook”。你可以設定標題或任何其他屬性，直觀如下：

  
newbook.title = "Angle of Repose"
newbook.author = "Wallace Stegner"


  在這同時，你有一個物件在記憶體。這時你需要的是：

  
newbook.save


  …然後你的新書將會被寫入資料庫。Active Record 產生 SQL 告訴資料庫插入一筆資料。你還可以只用少少幾行的程式碼就可以做欄位檢查，並產生錯誤訊息。

  現在你想要在成千上萬中的資料庫找那本書。只要寫：

  
angle_of_repose = Book.find_by_title "Angle of Repose"


  …於是你得到物件被稱作 “angle_of_repose”，它有著所有從資料庫撈出來的資料。

  當然還有更多，不過也不會太多了; 操作對應網站資料的軟體物件是如此自然有威力的方式。在RoR，你有豐富的軟體物件對應到你的資料庫表格，這些物件被組合成 MVC 系統中的 “model” 層。

  你的程式碼與 model 物件互動，然後 Active Record 產生 SQL 讓資料庫如你所寫。你不需要撰寫任何資料庫SQL語法。正因為不需要讓你的程式與資料庫直接溝通，你也可以透過更改設定輕鬆更換資料庫軟體。

  VIEWS 和 CONTROLLERS

  要建立網頁，Rails 提供樣本系統可以輕易地使用一致的網頁結構，插入相同的元件不需要重複程式碼，展示來自資料庫的資料，顯示並處理表單。這些樣板組成MVC系統的 “view” 層。

  如果你是前端開發者，這是 Rails 中你應該特別專注的部份。你可以簡單假設你的 “view” 檔案將會處理任何你要顯示出來的資料變數。正如同 PHP 檔案混合了 PHP 程式碼和 HTML，一個典型的 Rails view 也是混合了 Ruby 和 HTML。繼續我們的書店範例，這裡是一段 view 程式碼顯示書的標題和作者：

  
<h1><%= book.title %></h1>
<p><%= book.author %></p>


  Ruby 程式碼被標記成 <%= and %>; 其餘則是HTML。HTML和Ruby程式碼的輸出結合後，建立出網頁。

  Rails 被整合成支援 Prototype 和 Scriptaculous Javascript 函式庫，再加上一個稱作 Ruby JavaScript(RJS) 用來建構 Ajax 使用者介面的厲害機制。你可以用 Ruby 幾乎完全所有事情，包括最終被執行在瀏覽器的 Javascript 程式碼 (Rails 框架會處理這些轉換)

  一個 “controller” 是一整塊Ruby程式碼用來與 Model 溝通，並準備資料給 view。任何view所需的資料都會先在 controller 用一組變數所組成。這個 controller 也在頁面載入好以後回應 Ajax 的需求。Controller 也提供多種其他功能，從使用者認證到錯誤處理等。

  慣例勝於設定 (Convention over Configuration)

  Rails 試圖努力對任何事情都去提供一個合理的預設值。根據這個稱作慣例勝於設定的哲學，Rails 大大降低了設定檔的需要。

  如果你依照Rails的慣例，將會有令人驚艷的成果，從路由request對應到正確的 controller 和 view，到驗證表單資料和顯示錯誤訊息，都可以直接運作。與其他語言和框架比較起來，它使用了更少程式去達到更多常見的任務。

  慣例勝於設定的方式對初學者可能會有點挫折，特別是如果是從一個已經存在的應用程式開始用起，因為會有隱藏的假設藏在程式碼裡面。這些假設會讓程式簡潔，但是當你不知道的時候也會造成困惑。但當你學習Rails慣例之後，Rails的所有事情就會變成有意義了。一旦當你建構全新的網站時，你將如虎添翼般，因為有這麼多已經為你定義好的東西。

  它並不完美

  Rails 的確有它的缺點。當應用程式滿足上述的甜蜜點時，這些缺點可以被忽略不計，但是在極端情況卻是很大的問題。

  Ruby 比大多數其他程式語言還來的慢。當然這幾年將會改善，但是他對少數應用程式來說這是一個缺點，的確是個問題。不過實際上對絕大多數的網站這並不是問題所在。

  對 MVC 框架的架空使用也將拖慢速度。仔細看大多數的Rails應用都執行良好，但是很多 Model 操作都可以經由調校降低對資料庫的存取次數。你常常可以徹底地降低資料庫操作：Rails 包含了強而有利的快取系統，常常被存取的網頁可以只被建立一次，然後被讀取很多次。

  Rails 應用程式也常常在hosting比PHP碰到更多的麻煩。因為Rails框架程式大小的關係，它需要一直使用記憶體，而不是只在有request的時候。你需要100-200MB的專用記憶體來維持一個低流量的Rails應用。對比的PHP則可以在一台機器裡跑上上百的應用，因為他們不需要佔據任何記憶體直到被存取。(譯註：這個局面已改變，請參考 mod_rails)

  因為那些伺服器需求，共用 Hosting 通常對 Rails 應用問問多多。一 VPS(虛擬專用伺服器)通常是最佳的選擇。設定一台Rails伺服器比起PHP是複雜許多。這在一兩年前也許是個大問題，不過現在有許多 hosting 公司已經對 Rails 提供專門的解決方案。

  這些伺服器的要求也導致Ruby on Rails hosting傾向比起其他平台和語言成本更昂貴些。如果你符合Rails的甜蜜點，相對於比起使用Rails得到的好處，你的網站應當足夠重要到可以負擔這些增加的hosting費用。

  學習曲線

  Rails 的複雜讓初學者比較難以開始：它需要花幾個月的時間來熟悉Rails全部。但是你可以先從學習如何打造一個基本的Rails網站。一旦你開始採用，你將逐漸補齊所需要的技能和知識。

  建構網站的開發者來自四方八方不同背景，大部分可以分成兩類：

  1. 有點子建構網站，而且只想學習剛剛好足夠多的技術。
  2. 看見網站就像看見程式的程式設計師。

  Ruby on Rails 由程式設計師建構，也是為了寫給程式設計師使用。所以如果你來自專業軟體開發背景，它將會比來自於網頁設計領域更容易熟悉。

  如果你不是軟體設計師，將有更多東西要學，但也不是不可能。學習一部分的Ruby，學點物件導向程序，那麼了解Rails也不會太困難。要使用Rails建構網站你只需要具備有限的一小部分的 Ruby 能力即可。

  你可以不需要運作在框架裡面的進階Ruby技巧。你不需要了解Rails內部運作，或內部技術(例如metaprogramming)。

  Rails 系統的許多實做技術來自於軟體開發領域，包括使用原始碼管理系統，一個自動測試框架，文件工具，和佈署工具。如果你正在做點對點式(ad-hoc)的網站開發，這些也許是陌生的觀念，但是一旦你開始熟悉，它將讓你的工作生涯更健全。

  該學什麼

  學習 Rails 的奧祕在於知道什麼是你學習一開始可以忽略的東西，如此你才可以先在一段時間內牢記所知，而不是一次就用眼花撩亂的技術來構成Rails應用(一個學習開端是利用此文作者的 Ruby on Rails 免費線上課程）

  開始學習基本的Ruby。你不需要學太深，但是要有效率的開發Rails你必須知道這些基本的東西。Rails 看起來有點像標記語言(markup)，它也試圖這樣想，但你必須了解到網站並不是一組網頁檔案，而是由程式來產生網頁。

  如果你專注在前端，學習如何 layout, view 樣板，還有局部樣板(partials)是如何運作的。如果你是專注在後端開發，它將關注在 model 和 controller 層而並提供 view 所需要的變數。

  一開始，你可以忽略 Ajax; 它是一個可以大大改善使用者經驗的另一層技術，但是它真的不是必要的。所以當你學習 Rails 的時候可以先把 RJS, Prototype 和 Scriptaculous 放一邊。當你已經會基本東西之後，再來加入新潮的 Ajax 功能。

  如果你是後端開發者，專注在學習如何塑模你的應用領域成為一組資源，建立你的資料庫表格，然後使用物件。Rails 框架既廣且深，所以你將持續花時間學習，但是一開始你不需要太多。

  當你正在學習 Rails，你可以忽略測試和其相關的複雜東西，即使它在 Rails 的討論中非常值得關注。當你更進一步，回來在做即可。不要讓這些東西拖慢你一開始的學習或是增加你的認知負擔。

  換你上場了!

  一旦你準備好要加速了，Ruby on Rails 將變成一位老朋友。你的手指尖有著滿滿的工具，你將有著前所未有的生產效率。
  用更少程式碼做更多事情，你將樂於其中建構出更好的網站。不會再回頭了。

  原文插圖來自Kevin Cornell

  關於作者

  Michael Slater 是Collective Knowledge Works, Inc.的老闆，這家公司建立知識社群平台。他同時也是Learning Rails free online course的共同創辦人和BuildingWebApps.com的編輯主任。

  Translated with the permission of A List Apart Magazine and the author[s].

• May 21, 2008
• 2:57

  使用 mod_rails 當做開發環境

   » ‎ {|ihower.idv.tw| blog }

  Update(2008/6/25): 提昇 MacOS 開發爽度請裝 Pane Putting the pane back into deployment
  Update(2008/5/24): 更多參考連結 28 mod_rails / Passenger Resources To Help You Deploy Rails Applications Faster

  

  mod_rails(學名是 Passenger) 出來一段時間了，陸續開始有些使用經驗分享出來，在 production 上還蠻適合RAM有限的 VPS 環境，而這篇 Ask Your Doctor About mod_rails則介紹 mod_rails 也十分適合拿來當做 development 環境，也讓我十分心動：

  1. 厭倦每次都得 mongral_rails start 或 script/server？而且還要佔 terminal tabs。像我手上同時間好幾個案子(?!)，常常要切來切去還挺麻煩的。有了 mod_rails 設定好之後，每個網站都隨時 ready 可以用。(怕 memory 浪費?mod_rails 可以經由設定 RailsPoolIdleTime, RailsMaxPoolSize 來限制 process 存在的時間跟數量)
  2. 單一 mongrel process 沒辦法平行處理 requests，當網站圖片東西比較多的時候，速度就慢了。而 mod_rails 在有額外的 request 需求時，會 new process 來支援。
  3. 有 Apache 就可以設定 SSL，只用 mongrel 沒辦法測試 [HTTPS] 連線。

  心動了當然得馬上行動，參考了這篇 Using Passenger on OSX for Rails development，我很順利地在我的 Mac Leopard 上架了起來：

  1.安裝 Passenger：
  
gem install passenger
passenger-install-apache2-module


  2.設定 Apache，編輯 /etc/apache2/httpd.conf 或 /etc/apache2/users/ihower.conf，以下是一個範例 (前三行請參考執行 passenger-install-apache2-module 時顯示的訊息) ：

  
LoadModule passenger_module /opt/local/lib/ruby/gems/1.8/gems/passenger-2.0.1/ext/apache2/mod_passenger.so
PassengerRoot /opt/local/lib/ruby/gems/1.8/gems/passenger-2.0.1
PassengerRuby /opt/local/bin/ruby
PassengerMaxPoolSize 3
PassengerPoolIdleTime 300
RailsEnv development

  <Directory "/Users/ihower/RailsCode">
  Order allow,deny
  Allow from all
  </Directory>

  NameVirtualHost *:80

  <VirtualHost *:80>
  DocumentRoot "/Users/ihower/RailsCode/project1/public"
  ServerName project1.local
  </VirtualHost>

  <VirtualHost *:80>
  DocumentRoot "/Users/ihower/RailsCode/project2/public"
  ServerName project2.local
  </VirtualHost>

  3. 設定 /etc/hosts 指定本地端 domain：
  
127.0.0.1 project1.local
127.0.0.1 project2.local


  4.打開 Mac 上的 System Preferences ➔ Sharing ➔ Web Sharing，啟動 Apache。
  5.打開你的瀏覽器，輸入 project1.local, project2.local 順利的話就可以看到啦。

  問: 修改了 /vendor/ 下面的東西要重新載入怎麼辦?
  答：mod_rails 的用法挺有趣的，請執行：
  
touch tmp/restart.txt


  如果要一直修改 vendor 的話(在寫plugin嗎?)，可以下載 Automation with RStakeout，然後執行：
  
ruby rstakeout.rb "touch tmp/restart.txt" "vendor/**/*"

  這樣一有更動就會reload了，cool。

• May 19, 2008
• 6:53

  Github 分散式版本控制的殺手級應用

   » ‎ {|ihower.idv.tw| blog }

  最近常常推薦人家去玩 Github，到底有用在哪裡? 就來寫一篇廣告文吧。

  GitHub 是基於 Git 這套分散式版本控制系統的 Repository hosting 應用，一開始我也沒聽過 Git ，覺得用 Subversion 好好的為什麼這些人要換。抱著嚐鮮的念頭用了之後，發現實在好玩極了。目前已經有非常多的 Rails 相關應用都已經在上面進行開發，包括Ruby on Rails core、RSpec、will_paginate plugin、attachment fu_plugin等等，幾乎所有我用到的 Rails plugins 在上面都可以找的到。

  到底有那些特色呢?

  1. 你可以 watch 你所關注的專案，Github 提供 private RSS 訂閱。有了這個功能，我有用到的 plugins 的進度我都可以掌握。
  2. 可以看到哪個專案最多人 watch，比較哪個比較多人用(比較多人用比較保險?)。
  3. 你可以 follow 你所關注的開發者動態(例如ihower)，看看又有什麼新的好東西 :p
  4. 你可以對專案 fork 出自己的版本進行開發，甚至最後發 pull request 要求 merge。
  5. 根據 fork 我就可以看到這個專案的分支 Network 狀態。有時候可能本來的程式不好用或爛掉了，你就可以查看看有沒有人寫做 patch 改進。
  6. 漂亮的 Source code browser，並可以針對 commit 來做留言討論，甚至標明是 source code 的哪一行(請把滑鼠移到原始碼的行數旁)。
  7. 提供 tarball 下載，即使沒裝 git command 也十分方便下載。
  8. GitHub 可以直接當做 Ruby gem server
  9. 針對 Repository 可以搜尋 code, commit message, author 等
  10. Git (我的感覺)比 SVN 又快又穩，用 SVN 常常會因為檔案太多中途失敗。

  Github 根本就是 Open source developer 的 social networking 啊，聽說這股浪潮已經從 Ruby/Rails 圈吹到 JavaScript 跟 Perl 了(?)，這都要歸功於 Git 這套優異的分散式版本控制系統。

  BTW，幫忙宣傳 Jserv 在這週二的演講：我愛 Git - 有效使用分散式版本控制系統。

• May 13, 2008
• 23:26

  Ruby & Rails on Rails 進階書單

   » ‎ {|ihower.idv.tw| blog }

  都2008年了，還看我前年列的書單讓我有點不安，只好再整理一次。這次不列”所有”了，紅了之後入門書太多。而是整理我覺得值得一念的書及PDF。

  Ruby

  • Ruby for Rails (Manning) 剛出中文翻譯版。重點請把第 13 章念熟
  • Programming Ruby (Pragmatic) 擺在案頭當參考書不錯(?)
  • The Ruby Way 2nd. (Addison Wesley) 新 Ruby bible，請把第 11 章念熟
  • Writing Efficient Ruby Code (Addison Wesley shortcut PDF) 請看我之前寫的推薦：如何寫出有效率的 Ruby Code

  Ruby on Rails

  • Agile Web Development with Rails (Pragmatic) 剛出第三版 beta。
  • The Rails Way (Addison Wesley) 新 Rails bible。
  • Code Review (Peepcode) 請看我之前寫的推薦
  • Plugin Patterns (Peepcode) 想學會寫 Rails plugin 請看這份 PDF
  • Advanced Rails Recipes (Pragmatic) 每篇都很精彩的 Rails 食譜。像我個人就不喜歡 O’Reilly 的食譜，太充數了。
  • RJS Templates for Rails (O’Reilly shortcut PDF) 蠻不錯的 RJS PDF
  • Advanced Rails (O’Reilly)難得真的有 Advanced 到的書